The rts package uses GCC's __atomic built-in functions on 64-bit values. This
is not supported on some 32bit platforms (e.g., mipsel) resulting in the
following compilation error:
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_load_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_store_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_fetch_add_8'
Fix this by linking against libatomic.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/20549
Forwarded: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6820
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
The rts package uses GCC's __atomic built-in functions on 64-bit values. This
is not supported on some 32bit platforms (e.g., mipsel) resulting in the
following compilation error:
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_load_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_store_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_fetch_add_8'
Fix this by linking against libatomic.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/20549
Forwarded: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6820
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
The rts package uses GCC's __atomic built-in functions on 64-bit values. This
is not supported on some 32bit platforms (e.g., mipsel) resulting in the
following compilation error:
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_load_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_store_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_fetch_add_8'
Fix this by linking against libatomic.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/20549
Forwarded: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6820
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
Peter Trommler [Thu, 11 Jun 2020 06:31:22 +0000 (08:31 +0200)]
[PATCH] FFI: Fix pass small ints in foreign call wrappers
The Haskell calling convention requires integer parameters smaller
than wordsize to be promoted to wordsize (where the upper bits are
don't care). To access such small integer parameter read a word from
the parameter array and then cast that word to the small integer
target type.
Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).
Commit af9b744bbf1 introduced a regression stopping existing unregisterised
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `includes/stg/MiscClosures.h` file
where some defines have been renamed, resulting in the following error:
.
error: ‘stg_atomicModifyMutVarzh’ undeclared (first use in this function); did you mean ‘stg_atomicModifyMutVar2zh’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/17111.
.
This patch can be removed, once ghc-8.6 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/17111
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
* Disable parallel install to fix races with missing directories
(Closes: #944493)
* Fix FTBFS with autoconf 2.71. Thanks to Matthias Klose for the patch
(Closes: #995036)
* Fix FTBFS with Sphinx 4.2.0 (Closes: #995429)
Peter Trommler [Thu, 11 Jun 2020 06:31:22 +0000 (08:31 +0200)]
[PATCH] FFI: Fix pass small ints in foreign call wrappers
The Haskell calling convention requires integer parameters smaller
than wordsize to be promoted to wordsize (where the upper bits are
don't care). To access such small integer parameter read a word from
the parameter array and then cast that word to the small integer
target type.
Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).
Commit af9b744bbf1 introduced a regression stopping existing unregisterised
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `includes/stg/MiscClosures.h` file
where some defines have been renamed, resulting in the following error:
.
error: ‘stg_atomicModifyMutVarzh’ undeclared (first use in this function); did you mean ‘stg_atomicModifyMutVar2zh’?
.
For more information, see https://gitlab.haskell.org/ghc/ghc/issues/17111.
.
This patch can be removed, once ghc-8.6 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/17111
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
projects / ghc.git / log